Update. Got through review with no issues. I’m guessing the interface just doesn’t hide the iPad screenshots as of now.

Sounds good! Will try and catch it.

Yeah sounds good. It's possible these have different answers. The other question is somewhat poorly scoped and this was one isolated portion of it I thought could help crack it thats less specific to my use case. This makes sense let's go that route. Thanks for your help.

Also @DTS Engineer a bit of an AHA moment. And thank you that was a great idea haha. Using BUILT_PRODUCTS_DIR as the output destination for the script rather than DERIVED_FILE_DIR is the solution to this problem. The core issue of this is how to link the folder that is output from the aggregate build target. This is difficult because: Since Xcode 16 Xcode wants to work with PBXFileSystemSynchronizedRootGroup's not folders. This makes it (I think) impossible through the UI to link the folder that is output. I had to manually modify my project file. If you use DERIVED_FILE_DIR it makes a separate directory for each target. Making it difficult for your folder reference to stay the same between debug and release builds. Anywho that solves this portion of the problem. Other little bit. Xcode complained about multiple things writing to the same location with $(BUILT_PRODUCTS_DIR)/ in the output file list (that works just fine for DERIVED_FILE_DIR so I can only assume the entire BUILT_PRODUCTS_DIR is reserved. I just had to change it to $(BUILT_PRODUCTS_DIR)/build/

@DTS Engineer Love that video. I am not sure a custom build rule is a fit for my needs. From the documentation A build rule is the preferred way to process files that are independent from each other. Which I do not think applies here. There is a large bundle of react JS files that are compiled into a handful of html/css/resources in a folder. However that comment about BUILT_PRODUCTS_DIR does seem on point and resolves another question I had. Here's what remains. I seem to need to add the aggregate target that outputs to ${BUILT_PRODUCTS_DIR}/build as a target dependency. Otherwise Xcode does not seem to realize that even though the script in the aggregate output target outputs to ${BUILT_PRODUCTS_DIR}/build and that ${BUILT_PRODUCTS_DIR}/build is a resource copied in "copy bundle resources" that it needs to run the aggregate target. When I add the aggregate target as a target dependency it runs every time and does not seem to benefit from the dependency analysis check even if just building the aggregate target does benefit. Is this how things are supposed to work or is there a way to get the aggregate target (when added as a target dependency) to have its run script phase ran based on dependency analysis as normal?

The only reason I am going for an aggregate target is that I need this web bundle to be shared by two separate targets. In my head if I could get it so that it knew when to re-run the script in an aggregate target it would be easy to do so when I added the aggregate targets to the main targets. I guess a question would be what would I expect the difference to be if I ran the script in the main target as opposed to the aggregate? Is there a reason that would help dependency analysis do the right thing easier. (I need to try it again but last time I did it was no help) breaking this off into its own question.